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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

3GPP TS 32.150: "Integration Reference Point (IRP) Concept and definitions". 

3GPP TS 32.151: "Integration Reference Point (IRP) Information Service (IS) template". 

3GPP TS 32.152: "Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language 
(UML) repertoire". 
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Scope 



The present document contains the template to be used for the production of all Integration Reference Point (IRP) 
Information Service (IS) specifications within the 3GPP 32-series. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[4] 3GPP TS 32.152: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) Unified Modelling Language (UML) repertoire". 

[5] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[6] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point (IRP): Information Service". 

[7] 3GPP TS 32.302: "Telecommunication Management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

IRPAgent: See 3GPP TS 32.102 [2]. 

IRPManager: See 3GPP TS 32.102 [2]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 
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OMG 
UML 



Object Management Group 

Unified Modelling Language (OMG) 



Information Service (IS) template 



The present document contains the template to be used for the production of all Integration Reference Point (IRP) 
Information Service (IS) specifications within the 3GPP 32-series. 

The clauses in this template that shall be used in the IS specifications are numbered starting with "X", which in general 
should correspond to clause 4 that is the beginning of the main part of the TS. However, if there is a need in a specific 
IS to introduce additional clauses in the body, X may correspond to a number higher than 4. For a Network Resource 
Model (NRM) IRP IS, only clause X shall be used. 

The IS template uses qualifiers M, O, CM, CO and C. The semantics of these qualifiers are defined in TS 32.150 [3]. 

The introductory clauses (from clause 1 to clause 3) for the IS should be taken from the standard 3GPP TS template 
(i.e. not this IRP IS template). 

Usage of fonts shall be according to the following table. 



Item 


Font 


Class names 


Courier 


Attribute names 


Courier 


Operation names 


Courier 


Parameter names 


Courier 


Assertion names 


Courier 


Notification names 


Courier 


Exception names 


Courier 


State names 


Arial 


Enumerated values 


Arial 



X Information Object Classes 

"X" represents a clause number in the actual Information Service TS. 

X.1 Imported information entities and local labels 

This clause identifies a list of information entities (e.g. information object class, information relationship, information 
attribute) that have been defined in other specifications and that are imported in the present document. This includes 
information entities from other specifications imported for inheritance purpose. Each element of this list is a pair (label 
reference, local label). The label reference contains the name of the specification where it is defined, the type of the 
information entity and its name. The local label of imported information entities can then be used throughout the 
specification instead of the label reference. 

This information is provided in a table. An example of such a table is given here below: 



Label reference 


Local label 


3GPP TS 32.622 [5], information object class, Top 


Top 



X.2 Class diagram 

X.2.1 Attributes and relationships 

This first diagram represents all information object classes defined in this IS with all their relationships and all their 
attributes. This diagram shall contain relationship names, role name and role cardinality. This shall be a UML 
compliant class diagram (see also 3GPP TS 32.152 [4]). 
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Characteristics (attributes, relationships) of imported information object classes need not to be repeated in the 
diagram. Information object classes should be defined using the stereotype «InformationObjectClass». 

X.2.2 Inheritance 

This second diagram represents the inheritance hierarchy of all information object classes defined in this IS. This 
diagram does not need to contain the complete inheritance hierarchy but shall at least contain the parent information 
object classes of all information object classes defined in the present document. By default, an information object class 
inherits from the information object class "top". This shall be a UML compliant class diagram. 

Characteristics (attributes, relationships) of imported information object classes need not to be repeated in the 
diagram. Information object classes should be defined using the stereotype «InformationObjectClass». 

NOTE: some inheritance relationships presented in clause X.2.2 can be repeated in clause X.2.1 to enhance 
readability. 

X.3 Information object class definitions 

Each information object class is defined using the following structure. 

X.3. a InformationObjectClassName 

InformationObjectClassName is the name of the information object class. 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an information object class. 

X.3.a.1 Definition 

The <definition> subclause is written in natural language. The <definition> subclause refers to the information object 
class itself. The characteristics related to the relationships that the object class can have with other object classes can't 
be found in the definition. The reader has to refer to relationships definition to find such kind of information. 
Information related to inheritance shall be precised here. 

X.3.a.2 Attributes 

The <attributes> subclause presents the list of attributes, which are the manageable properties of the object class. 
Each element is a tuple (attributeName, visibilityQualifier, supportQualifier, readQualifier, writeQualifier): 

The visibilityQualifier indicates whether the attribute is public, private or IRPAgent Internal ("+ ", " — ", and "%" 
respectively). The semantics of public and private are as per the UML specification. The semantic of IRPAgent 
Internal is defined within the 3GPP UML Repertoire (3GPP TS 32.152 [4]). 

The supportQualifier indicates whether the attribute is Mandatory, Optional, Conditional or not supported 
("M","0","C", or " — ", respectively). 

The supportQualifier indicates whether the attribute is Mandatory (M), Optional (O), Conditional-Mandatory 
(CM), Conditional-Optional (CO), SS-Conditional (C) or not supported ( — ). 

The writeQualifier indicates whether the attribute shall be writeable by the IRPManager. The semantics for 
writeQualifier is identical to supportQualifier, for "M", "O", and " — ". 

There is a dependency relationship between the supportQualifier and visibilityQualifier, readQualifier, and 
writeQualifier. The supportQualifier indicates the requirements for the support of the attribute. For any given attribute, 
regardless of the value of the supportQualifier, at least one of the readQualifier or writeQualifier must be "M". The 
implication of the "O" supportQualifier is that the attribute is optional, however the read and write qualifiers indicate 
how the optional attribute shall be supported, should the optional attribute be supported. Regardless of the 
supportQualifier, if an attribute is supported then it shall be supported in accordance with the specified 
visibilityQualifier. 

Private or IRPAgent Internal attributes are per definition not readable by the IRPManager. Their readQualifier is 
hence always " — ". 
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Private or IRP Agent Internal attributes are per definition not writable by the IRPManager. Their writeQualifier is 
hence always " — ". 

The readQualifier and writeQualifier of a supported attribute, that is public, may not be both " — ". 

The use of " — " in supportQualifier is reserved for documenting support of attributes defined by an «Archetype» IOC. 
Attributes with a supportQualifier of " — " are not implemented by the IOC that is realizing a subset of the attributes 
defined by the «Archetype». The readQualifier and writeQualifier are of no relevance in this case. However, a not 
supported attribute is neither readable nor writable. For this reason the readQualifier and writeQualifier shall be " — " 
for unsupported attributes. 

For any IOC that uses one or more attributes from an «Archetype», a separate table shall be used to indicate the 
supported attributes. This table is absent if no « Archetype » attributes are supported. For example, if a particular IOC 
has defined attributes (i.e. attributes not defined by an «Archetype») and encapsulates attributes from two 
«Archetype»s, then the totality of the attributes of said IOC will be contained in three separate tables. 

This information is provided in a table. An example of such a table is given below: 



Attribute name 


Visibility 


Support Qualifier 


Read Qualifier 


Write Qualifier 


ntf Subscript ion Id 


+ 


M 


M 





Another example, where the support qualifier is "0" is given here below: 


Attribute name 


Visibility 


Support Qualifier 


Read Qualifier 


Write Qualifier 


ntf Subscript ion Id 


+ 





M 






In this example, the ntfSubscriptionId is an optional attribute. If the implementation chose to support ntfSubscriptionId, 
then the said implementation is required to support read and may support write. 

NOTE: This subclause does not need to be present when there is no attribute to define. 



X.3.a.3 



Attribute constraints 



The Kattribute constraints> subclause presents constraints between attributes that are always held to be true. Those 
properties are always held to be true during the lifetime of the attributes and in particular don't need to be repeated in 
pre or post conditions of operations or notifications. 

NOTE: This subclause does not need to be present when there are no attribute constraints to define. 



X.3.a.4 



Relationships 



The <relationship> subclause presents the list of relationships in which this class in involved. Each element is a 
relationshipName. 

NOTE: This subclause is optional and may be avoided since all relationships are represented in the class 
diagram in clause X.2.1. 



X.S.a.S 



State diagram 



The <state diagram> subclause contains state diagrams. A state diagram of an information object class defines 
permitted states of this information object class and the transitions between those states. A state is expressed in terms of 
individual attribute values or a combination of attribute values or involvement in relationships of the information object 
class being defined. This shall be a UML compliant state diagram. 

NOTE: This subclause does not need to be present when there is no state diagram to define. 



X.3.a.6 



Additional Notifications 



The <Additional notifications> subclause, for this IOC, presents the list of additional notifications (to the common 
notifications in section X.6), that can be emitted across the Itf-N, where the "object class" and "object instance" 



ETSI 



3GPP TS 32.151 version 6.2.0 Release 6 10 ETSI TS 132 151 V6.2.0 (2006-03) 

parameters of the notification header (see note 2) of these notifications identifies an instance of the IOC defined by the 
encapsulating subclause (i.e. clause X.3.a). Please refer to note 3. 

The notifications identified in this sub clause, may originate from implementation object(s) whose identifier is mapped 
in the implementation, to the object instance identifier used over the ITF-N. Hence The presence of notifications in this 
clause (i.e. clause X.3.a.6) does not imply nor identify those notifications as being originated from an instance of the 
IOC defined by the encapsulating subclause (i.e. clause X.3.a). 

This information is provided in a table. An example of such a table is given below: 



Name 


Qualifier 


Notes 






Additional Notifications to common notifications in section X.5 added here 



NOTE 1: This subclause and table dos not need to be present when there are no additional notifications to those in 
clause X.5.. 

NOTE 2: The notification header is defined in the notification IRP Information service TS 32.302 [7]. 

NOTE 3: This clause was modified during the closing stages of release 6, to help other SDOs re use the 3GPP IRP 
technique . 

Consequently not all 3GPP Information service specifications will be aligned during release 6. 
Some specificiations will have a single clause titled "Notifications" and will not have clause X.6. 
Complete alignment will be made during the next release. 

X.4 Information relationship definitions 

Each information relationship is defined using the following structure. 

X.4. a InformationRelationshipName (supportQualifier) 

InformationRelationshipName is the name of the information relationship followed by a qualifier indicating whether the 
relationship is Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or 
SS-Conditional (C). 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an information relationship. 

X.4.a.1 Definition 

The <definition> subclause is written in natural language. 

X.4.a.2 Roles 

The <roles> subclause identifies the roles played in the relationship by object classes. Each element is a pair 
(roleName, roleDefinition). 

This information is provided in a table. An example of such a table is given here below: 



Name 


Definition 


isSubscribedBy 


This role represents the one who has subscribed. 



X.4.a.3 Constraints 

The <constraints> subclause contains the list of properties specifying the semantic invariants that must be preserved on 
the relationship. Each element is a pair (propertyName, propertyDefinition). Those properties are always held to be 
true during the lifetime of the relationship and don't need to be repeated in pre or post conditions of operations or 
notifications. 

This information is provided in a table. An example of such a table is given here below: 
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Name 


Definition 


inv_notif icationCat 
egoriesAllDistinct 


The notification categories contained in the ntfNotificationCategorySet attribute of 
ntfSubscription playing the role hasSubscription are all distinct from each other. 



X.5 Information attribute definitions 

Each information attribute is defined using the following structure: 

X.5.1 Definition and legal values 

This subclause contains for each attribute being defined its name, its definition written in natural language and a list of 
legal values supported by the attribute. 

In the case where the legal values can be enumerated, each element is a pair (legalValueName, legalValueDefinition), 
unless a legalValueDefinition applies to several values in which case the definition is provided only once. When the 
legal values cannot be enumerated, the list of legal values is defined by a single definition. 

This information is provided in a table. An example of such a table is given here below: 



Attribute Name 


Definition 


Legal Values 


ntfSubscription Id 


It identifies uniquely a subscription 


N/A 


ntf SusbcriptionState 


It indicates the activation state of a subscription 


"suspended"; the subscription is 

suspended. 

"notSuspended".-the subscription is active. 



X.5. 2 Constraints 

The <constraints> subclause indicates whether there are any constraints affecting attributes. Each constraint is defined 
by a pair (propertyName, propertyDefinition). Property Definitions are expressed in natural language. 

An example is given here below: 



Name 


Definition 


inv_TimerConstraints 


The ntfTimeTickTimer is lower than or equal to ntfTimeTick. 



X.6 



Common Notifications 



This <Common Notifications> subclause presents the list of notifications that can be emitted across the Itf-N, where the 
"object class" and "object instance" parameters of the notification header(see Note 2) of these notifications identifies an 
instance of an IOC defined by this IRP specification. Please refer to Note 3 below. 

Exceptions if a small number oflOCs don"t support all of the notifications. 

The Notifications provided in the following table do not apply the following lOCs. 

The notifications in this sub clause, may originate from implementation objects, which are mapped by an 
implementation to the object instance used across the ITF-N. Hence the presence of notifications in this subclause 
(i.e. clauseX.6) does not imply nor identify those notifications as being originated from an instance of the IOC defined 
by this NRM IRP specification. 

This information is provided in a table. An example of such a table is given below: 
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Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP {3GPP TS 32.1 11-2 [6]) 


Example common notification 


notifyAttributeValueChange 





example 


notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [6]) 


example 


notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [6]) 


example 


notifyNewAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [6]) 


example 


not ifyObject Great ion 





example 


notifyOb jectDeletion 





example 



NOTE 1: This subclause does not need to be present when there are no common notifications. 

NOTE 2: The notification header is defined in the notification IRP Information service TS 32.302 [7]. 

NOTE 3: This clause was modified during the closing stages of release 6, to help other SDOs re use the 3GPP IRP 
technique. 

Consequently not all 3GPP Information Service specifications will be aligned during release 6. 
Some specificiations will have a single clause titled "Notifications" and will not have clause X.6. 
Complete alignment will be made during the next release. 

X.7 Particular information configurations 

Some configurations of information are special or complex enough to justify the usage of a state diagram to clarify 
them. A state diagram in this clause defines permitted states of the system and the transitions between those states. A 
state is expressed in terms of a combination of attribute values constraints or involvement in relationships of one or 
more information object classes. 



Y 



Interface Definition 



"Y" represents a number, immediately following "X". 

Y.1 Class diagram representing interfaces 

Each interface is defined in the diagram. This shall be a UML compliant class diagram (see also 3GPP TS 32.152 [A]}. 

Interfaces are defined using a stereotype «Interface». Each interface contains a set of either operations or 
notifications which are mandatory or either a single operation or a single notification which is optional. The support of 
an interface by an information object class is represented by a relationship between the 2 entities with a cardinality 
(1..1) if all the operations or notifications contained in the interface are mandatory, and (0..1) if the operation or 
notification contained in the interface is optional. On the class diagram, each operation and notification in an interface 
shall be qualified as "public" by the addition of a symbol "+" before each operation and notification. 

Y.2 Generic rules 

The following rules are relevant for all IS. They shall simply be copied as part of the template. 

Rule 1: each operation with at least one input parameter supports a pre-condition valid_input_parameter which 
indicates that all input parameters shall be valid with regards to their information type. Additionally, each such 
operation supports an exception operation_failed_invalid_input_parameter which is raised when pre-condition 
valid_input_parameter is false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and the 
pre-condition indicates that the operation supports the named optional input parameter. Additionally, each such 
operation supports an exception operation_failed_unsupported_optional_input_parameter_xxx which is raised when 
(a) the pre-condition supported_optional_input_parameter_xxx is false and (b) the named optional input parameter is 
carrying information. The exception has the same entry and exit state. 
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Rule 3: each operation shall support a generic exception operation_failed_internal_problem which is raised when an 
internal problem occurs and that the operation cannot be completed. The exception has the same entry and exit state. 

Y.b InterfaceName Interface (supportQualifier) 

InterfaceName is the name of the interface followed by a qualifier indicating whether the interface is Mandatory (M), 
Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C). 

"b" represents a number, starting at 3 and increasing by 1 with each new definition of an interface. 

Each interface is defined by its name and by a sequence of operations or notifications as defined here below. 

Each operation is defined using the following structure. 

Y.b. a Operation OperationName (supportQualifier) 

OperationName is the name of the operation followed by a qualifier indicating whether the operation is Mandatory 
(M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C). 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an operation. 

Y.b.a.1 Definition 

The <definition> subclause is written in natural language. 



Y.b.a.2 



Input parameters 



List of input parameters of the operation. Each element is a tuple (inputParameterName, supportQualifier, 
InformationType, inputParameterComment). Legal values for the supportQualifier are: Mandatory (M), Optional (O), 
Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C). 

This information is provided in a table. An example of such a table is given here below: 



Parameter Name 


Qualifier 


Information type 


Comment 


managerRef erence 


M 


ntfSubscriber.ntfManagerReference 


It specifies tlie reference of IRPIVIanager to which 
notifications shall be sent. 



Y.b.a.3 



Output parameters 



List of output parameters of the operation. Each element is a tuple (outputParameterName, supportQualifier, 
Matchinglnformation, outputParameterComment). Legal values for the supportQualifier are: Mandatory (M), Optional 
(O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C). 

This information is provided in a table. An example of such a table is given here below: 



Parameter Name 


Qualifier 


lUlatching Information 


Comment 


versionNumberSet 


M 


notificationlRP.irpversion 


It indicates one or more SS version numbers supported by the 
notificationlRP. 



Y.b.a.4 



Pre-condition 



A pre-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The pre-condition must be 
held to be true before the operation is invoked. An example is given here below: 

notificationCategoriesNotAllSubscribed OR notificationCategoriesParameterAbsentAndNotAllSubscribed 

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the pre-condition 
are provided in a table. An example of such a table is given here below: 
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Assertion Name 


Definition 


notificationCategor 
iesNot All Subscribed 


At least one notificationCategory identified in the notificationCategories input parameter is 
supported by IRPAgent and is not a member of tlie ntfNotificationCategorySet attribute of an 
ntfSubscription which is involved in a subscription relationship with the ntfSubscriber identified 
by the managerReference input parameter. 


notificationCategor 
iesParameter Absent A 
ndNot All Subscribed 


The notificationCategories input parameter is absent and at least one notificationCategory 
supported by IRPAgent is not a member of the ntfNotificationCategorySet attribute of an 
ntfSsubscription which is involved in a subscription relationship with the ntfSubscriber 
identified by the managerReference input parameter. 



Y.b.a.5 



Post-condition 



A post-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The post- condition must 
be held to be true after the completion of the operation. When nothing is said in a post-condition regarding an 
information entity, the assumption is that this information entity has not changed compared to what is stated in the 
pre-condition. An example is given here below: 

subscriptionDeleted OR allSubscriptionDeleted 

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the post-condition 
are provided in a table. An example of such a table is given here below: 



Assertion Name 


Definition 


subscriptionDeleted 


The ntfSubscription identified by subscriptionid input parameter is no more involved in a 
subscription relationship with the ntfSubscriber identified by the managerReference input 
parameter and has been deleted. If this ntfSubscriber has no more ntfSubscription, it is 
deleted as well. 


allSubscriptionDele 
ted 


In the case subscriptionid input parameter was absent, the ntfSubscriber identified by the 
managerReference input parameter is no more involved in any subscription relationship and 
is deleted, the corresponding ntfSubscription have been deleted as well. 



Y.b.a.6 Exceptions 

List of exceptions that can be raised by the operation. Each element is a tuple (exceptionName, condition, 
Retumedlnformation, exitState). 

Y.b.a.e.c exceptionName 

ExceptionName is the name of an exception. 

"c" represents a number, starting at 1 and increasing by 1 with each new definition of an exception. 

This information is provided in a table. An example of such a table is given here below: 



Exception Name 


Definition 


ope_f ailed_existing_subscription 


Condition: (notificationCategoriesNotAIISubscribed OR 
notificationCategoriesParameterAbsentAndNotAIISubscribed) not verified. 
Returned information: output parameter status is set to 
OperationFailedExistingSubscription. 
Exit state: Entry State. 



Each notification is defined using the following structure. 

Y.b.a.7 Constraints 

The < constraints> subclause presents constraints for the operation or its parameters. 

NOTE: This subclause does not need to be present when there are no constraints to define. 
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Y.b.a Notification NotificationName (supportQualifier) 

NotificationName is the name of the notification followed by a qualifier indicating whether the notification is 
Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C) 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of a notification. 

Y.b.a.1 Definition 

The <definition> subclause is written in natural language. 



Y.b.a.2 



Input parameters 



List of input parameters of the notification. Each element is a tuple (inputParameterName, supportQualifier and 
filteringQualifier, matchinglnformation, inputParameterComment). 

The column "Qualifiers" contains the two qualifiers, supportQualifier and filteringQualifier, separated by a comma. 
The supportQualifier indicates whether the attribute is Mandatory (M), Optional (O), Conditional-Mandatory (CM), 
Conditional-Optional (CO), or SS-Conditional (C). The filteringQualifier indicates whether the parameter of the 
notification can be filtered or not. Values are Yes (Y) or No (N). The matchinglnformation refers to information in the 
state "toState". 

This information is provided in a table. An example of such a table is given here below: 



Parameter Name 


Qualifiers 


IVIatching Information 


Comment 


managerRef erence 


M,Y 


ntfSubscriber.ntfManagerReference 


It specifies tlie reference of IRPIVIanager to whicli 
notifications sliall be sent. 



Y.b.a.3 



Triggering event 



The triggering event for the notification to be sent is the transition from the information state defined by the "from 
state" subclause to the information state defined by the "to state" subclause. 



Y.b.a.3.1 



From state 



This subclause is a collection of assertions joined by AND, OR, and NOT logical operators. An example is given here 
below: 

alarmMatched AND alarmlnformationNotCleared 

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the state "from 
state" are provided in a table. An example of such a table is given here below: 



Assertion Name 


Definition 


alarmMatched 


The newly generated network alarm matches with one Alarmlnformation (same values for 
eventType, probableCause, specificProblem attributes) in AlarmList. 


alarmlnf ormationNot 
Cleared 


The perceivedSeverity attribute of the matched Alarmlnformation is not cleared. 



Y.b.a.3.2 



To state 



This subclause is a collection of assertions joined by AND, OR and NOT logical operators. When nothing is said in a 
to-state regarding an information entity, the assumption is that this information entity has not changed compared to 
what is stated in the from state. An example is given here below: 

resetAcknowledgementlnformation AND perceivedSeverityUpdated 

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the state "to state" 
are provided in a table. An example of such a table is given here below: 
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Assertion Name 


Definition 


resetAcknowledgemen 
tinf ormation 


The matched Alarmlnformation identified in inv_alarmlVlatched in pre-condition has been 
updated according to the following rule: 

ackTime, ackUserld and ackSystemId are updated to contain no information; ackState is 
updated to "unacknowledged". 


perceivedSeverityUp 
dated 


The perceivedSeverity attribute of matched Alarmlnformation identified in inv_alarmMatched 
in pre-condition has been updated. 



Y.b.a.4 Constraints 

The < constramts> subclause presents constraints for the notification or its parameters. 

NOTE: This subclause does not need to be present when there are no constraints to define. 



Scenario 



"Z" represents a number, immediately following "Y". 

This clause contains one or more sequence diagrams, each describing a possible scenario. This shall be a UML 
compliant sequence diagram. This is an optional clause. 



ETSI 



3GPP TS 32.151 version 6.2.0 Release 6 



17 



ETSI TS 132 151 V6.2.0 (2006-03) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Cat 


Old 


New 


Dec 2003 


SA 22 


SP-030614 


-- 


-- 


Submitted to TSG SA#22 for Information 


-- 


1.0.0 




Mar 2004 


SA 23 


SP-040114 


-- 


-- 


Submitted to TSG SA#23 for Approval 


-- 


2.0.0 


6.0.0 


Mar 2005 


SA_27 


SP-050023 


0001 


— 


Address 3GPP2 Liaison point 8 from tdoc S5-048704 to have a common 
notifications section 


C 


6.0.0 


6.1.0 


Jun 2005 


SA 28 


-- 


-- 


-- 


Moved TS-family overview from Scope to Introduction (new Clause) 


-- 


6.1.0 


6.1.1 


Mar 2006 


SA 31 


SP-060098 


0002 




Correction to Conditional qualifiers 


F 


6.1.1 


6.2.0 





















£75/ 



3GPP TS 32.151 version 6.2.0 Release 6 



18 



ETSI TS 132 151 V6.2.0 (2006-03) 



History 



Document history 


V6.0.0 


March 2004 


PubHcation 


V6.1.0 


March 2005 


PubHcation (Withdrawn) 


V6.1.1 


June 2005 


PubHcation 


V6.2.0 


March 2006 


PubHcation 









£75/ 



